feat(plugins): add DocuSign eSignature integration plugin - #1146

@likithdt is attempting to deploy a commit to the corsair Team on Vercel.

A member of the Team first needs to authorize it.

sequenceDiagram
  participant EndpointHandler
  participant DocusignClient
  participant DocuSignAPI
  EndpointHandler->>DocusignClient: Provide endpoint parameters
  DocusignClient->>DocuSignAPI: Send authenticated JSON request
  DocuSignAPI-->>DocusignClient: Return JSON response or HTTP error
  DocusignClient-->>EndpointHandler: Return parsed response or throw error

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Greptile Summary

The PR adds and registers a DocuSign plugin with six envelope/template operations, OAuth bearer transport, schemas, error policies, tests, and webhook handling. Several previously reported runtime and contract failures remain:

• Bound operations still cannot obtain a DocuSign client from Corsair's execution context.
• Rate-limit responses are still not represented or retried using Corsair's supported policy contract.
• Direct webhook events remain unauthenticated.
• Much of the API surface promised by the PR remains absent.

Confidence Score: 0/5

The PR is not safe to merge because operations still fail during runtime binding, rate limits are not retried, direct webhooks remain forgeable, and promised operations remain unavailable.

The endpoint resolver requires a client that Corsair's bound context does not provide, the registered rate-limit handler returns an unsupported strategy shape, webhook matching has no provider-signature gate, and the endpoint tree omits multiple capabilities claimed by the PR.

Files Needing Attention: packages/docusign/endpoints/context.ts, packages/docusign/index.ts, packages/docusign/error-handlers.ts, packages/docusign/client.ts, packages/docusign/webhooks/index.ts

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Caller[Caller] --> Bind[Corsair endpoint binding]
  Bind --> Context[Runtime execution context]
  Context --> Resolver[resolveClient]
  Resolver -->|No client or request member| Failure[Operation throws]
  Direct[Direct webhook request] --> Matcher[Payload-shape matcher]
  Matcher -->|No signature verification| Handler[Event accepted]

_{Reviews (6): Last reviewed commit: "fix(docusign): update endpoint context t..." | Re-trigger Greptile}

Plugin PR scorecard — packages/docusign

Rules: PLUGIN_PR_RULES.md · re-runs on every push

Hey @likithdt, thanks for the contribution! 🏴‍☠️ Before a maintainer reviews, please fix the items below — the review re-runs automatically on your next push.

Must fix

• P1 packages/docusign/client.ts:16 — Credentials target placeholder host
  When example.get runs with a configured API key or OAuth token, the client joins its path to https://api.example.com and sends the credential there as a Bearer token, causing the operation to miss DocuSign and disclose the credential to a non-DocuSign host.

How this was verified: The request implementation constructs the URL from BASE and emits TOKEN in the Authorization header.

Rule Used: Flag boilerplate residue from the plugin generator... (source)

Knowledge Base Used: Provider plugin implementation conventions

• P1 packages/docusign/webhooks/types.ts:58 — Webhook verification always succeeds
  When an attacker supplies any x-docusign-signature header and an example payload, the handler's sole authentication gate returns valid without inspecting the request or secret, causing the forged event to be logged and accepted as a successful DocuSign webhook.

How this was verified: The direct webhook path reaches this unconditional verifier without another provider-signature check.

Knowledge Base Used:

• Provider plugin implementation conventions
• OAuth, subscriptions, and webhook delivery
• P1 packages/docusign/index.ts:78 — Advertised operations are absent
  When consumers attempt to use the envelope, template, DocGen, user, signing-group, custom-field, or brand operations described by this PR, the published endpoint tree provides only example.get, so none of those advertised DocuSign capabilities is callable.

Rule Used: Verify the implementation matches the PR descripti... (source)

Knowledge Base Used: Provider plugin implementation conventions

• P1 packages/docusign/schema.test.ts:18 — Endpoint behavior remains untested
  The only test file asserts schema version and entity metadata without invoking example.get, so broken request paths, methods, authentication, and response contracts can pass the package test suite.

Rule Used: Plugin packages must include at least one *.test.t... (source)

Knowledge Base Used: Provider plugin implementation conventions

• P1 packages/docusign/client.ts:60 — Rate-limit metadata is discarded
  When the provider returns HTTP 429 with retry metadata, this catch block replaces ApiError with DocusignAPIError and drops its status and retryAfter, causing a normal “Too Many Requests” response to fall through to the non-retrying default handler.

	} catch (error) {
		if (error instanceof Error) {
			throw error;
		}
		throw new DocusignAPIError('Unknown error');
	}

Rule Used: Every endpoint must validate inputs and outputs wi... (source)

Knowledge Base Used:

• Provider plugin implementation conventions
• Plugin lifecycle and operations

PR requirements (rules)

• R4 — Required in "Screenshots / Demos" before a maintainer reviews

If anything remains after your next push, a maintainer will take it from there and do the final review and merge.

@Mayank-saraswal, please check my issue because it is complete and it is still not merged.
There is an a task failing with Vercel, I think it is not required and it also need authorization.

@greptileai review

Maintainer review needed

Automated rounds are exhausted. Remaining findings:

• P1 packages/docusign/index.ts:21 — Endpoint binding always fails
  When a consumer invokes any newly registered DocuSign operation through Corsair, the runtime passes its execution context as the first argument, but these handlers treat that value as a DocusignClient and call client.request, causing every operation to fail with client.request is not a function.

Rule Used: Verify the implementation matches the PR descripti... (source)

Knowledge Base Used:

• Provider plugin implementation conventions
• Plugin lifecycle and operations
• P1 packages/docusign/index.ts — Endpoint schemas remain unregistered
  When runtime inspection or invocation requests a contract for one of these operations, the plugin has no endpointSchemas property, so the declared input and output Zod schemas are neither exposed nor applied at the Corsair operation boundary.

Rule Used: Every endpoint must validate inputs and outputs wi... (source)

Knowledge Base Used:

• Provider plugin implementation conventions
• Plugin lifecycle and operations
• P1 packages/docusign/webhooks/index.ts — Webhook payload is discarded
  When Corsair dispatches a legitimate DocuSign event, it supplies the normalized event in request.payload, but this handler reads request.body and then treats the request wrapper as the event, causing the event name and envelope ID to be lost and returning wrapper metadata instead of the provider payload.

Knowledge Base Used: OAuth, subscriptions, and webhook delivery

@likithdt Hey , could you please fix the latest issues that greptile found ?

@likithdt Hey , could you please fix the latest issues that greptile found ?

sure,

@Mayank-saraswal please check..

@greptileai review

@greptileai review

@greptileai review

@greptileai review

@Mayank-saraswal please check now bro, even greptileai is also having no issues now..

@likithdt hey bro, thanks for the PR and the work so far. one big thing before we can move forward here.

the oss page for this integration (https://corsair.dev/oss/docusign) lists 339 operations for the docusign catalog, but this PR only implements 6 of them (createEnvelope, getEnvelope, sendEnvelope, createRecipientViewUrl, listTemplates, getTemplate). that is around 2 percent of the surface.

the expectation for plugin PRs in this repo is to implement the full operation list from the oss page.

please implement all 339 operations from the oss page with their zod input and output schemas,

ping here if you want to discuss. thanks.

@likithdt hey bro, thanks for the PR and the work so far. one big thing before we can move forward here.

the oss page for this integration (https://corsair.dev/oss/docusign) lists 339 operations for the docusign catalog, but this PR only implements 6 of them (createEnvelope, getEnvelope, sendEnvelope, createRecipientViewUrl, listTemplates, getTemplate). that is around 2 percent of the surface.

the expectation for plugin PRs in this repo is to implement the full operation list from the oss page.

please implement all 339 operations from the oss page with their zod input and output schemas,

ping here if you want to discuss. thanks.

@Mayank-saraswal Bro, Seriously, its not even mentioned anywhere that we have to complete all the 339 operations, neither in the site, nor in the rules, and not even mentioned in the demo video. Also bro do you think it is possible to do all 339 operations before the deadline. and also bro the page itself doesn't show us the list of all 339 operations, it just shows us some 90-100 operations. where do i find the rest of them..

Bro, don't you think it is unfair that you are asking to do all the 339 Operations to be done just for round 1. This isn't the Main Round too. Well it's not about that I can't. It is possible and i can do it, but bro tell me is it fair, what you are asking for..

Well if you want any help in doing all 339 operations and helping out the open-source community, I surely will, but lets talk about that after the hackathon.

@likithdt hey bro, thanks for the PR and the work so far. one big thing before we can move forward here.
the oss page for this integration (https://corsair.dev/oss/docusign) lists 339 operations for the docusign catalog, but this PR only implements 6 of them (createEnvelope, getEnvelope, sendEnvelope, createRecipientViewUrl, listTemplates, getTemplate). that is around 2 percent of the surface.
the expectation for plugin PRs in this repo is to implement the full operation list from the oss page.
please implement all 339 operations from the oss page with their zod input and output schemas,
ping here if you want to discuss. thanks.

@Mayank-saraswal Bro, Seriously, its not even mentioned anywhere that we have to complete all the 339 operations, neither in the site, nor in the rules, and not even mentioned in the demo video. Also bro do you think it is possible to do all 339 operations before the deadline. and also bro the page itself doesn't show us the list of all 339 operations, it just shows us some 90-100 operations. where do i find the rest of them..

Bro, don't you think it is unfair that you are asking to do all the 339 Operations to be done just for round 1. This isn't the Main Round too. Well it's not about that I can't. It is possible and i can do it, but bro tell me is it fair, what you are asking for..

Well if you want any help in doing all 339 operations and helping out the open-source community, I surely will, but lets talk about that after the hackathon.

@likithdt That's why we have mentioned to create PR as draft and attach link in /oss site.
there is properly mentioned of all operations you have to do.